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Bhagavath 12-30-24-5 

A Network-Based Service for Originator-Initiated 
Automatic Repair of IP Multicast Sessions 

Inventors: Vijay K. Bhagavath, Joseph T. ©"Neil, David Shur, and Aleksandr Zelezniak 

Related Patent Applications 

This patent appUcation is related to the copending US Patent Apphcation Serial 
Number 09/271,1 16, filed March 17, 1999, entitled "A Network-Based Service for the 
Repair of IP Multicast Sessions", by Nicholas Maxemchuk, David McManamon, David 
Shur, and Aleksandr Zelezniak, assigned to AT&T Corp. and incorporated herein by 
reference. 

Background Of The Invention 

IP multicasting provides an efficient way for a source to send a stream of User 
Datagram Protocol (UDP) packets to a set of recipients. The source sends only one copy 
of each packet to an IP network, such as the Internet, for example. The routers in the IP 
network do the work required to deliver that packet to each recipient. Various IP 
multicast routing protocols can be used in an IP network. These allow the routers to 
communicate with each other so that the multicast datagrams are sent only to those 
subnetworks with receivers that have joined a multicast session. 

A multicast session is identified by an IP address and port nixmber. The IP 
address is a Class D address in the range from 224.0.0.1 to 239.255.255.255. IP 
multicasting is more efficient than unicasting for group communication. Unicasting 
requires that the source send a separate copy of each datagram to each recipient. This 
requires exti-a resources at the source and m the IP network and is wasteful of network 
bandwidth. 
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Some useful background references describing IP multicasting in greater detail 
include: (1) Kosiur, D., "IP Multicasting: The Complete Guide to Corporate Networks", 
Wiley, 1998; (2) Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 
1997; (3) Deering, S., "Host Extensions for IP Multicasting," Network Working Group 
5 Request for Comments Internet RFC-1 1 12, August 1989; .(4) Waitzman, D., Partridge, 
C, Deering, S., "Distance Vector Multicasting Routing Protocol," Network Working 
Group Request for Comments Internet RFC-1 075, November 1988; (5) Schulzrinne, H., 
Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time 
Applications," Network Working Group Request for Comments Internet RFC 1889, July 
10 18,1 994. The IP multicast protocol set forth in the IETF RFC 1112 "Host Extensions for 
IP Multicasting" is the standard protocol for enabhng hosts to establish and conduct IP 
multicast sessions on the Internet. The IETF RFC 1 075, "Distance Vector Multicast 
d:i Routing Protocol (DVMRP)," describes a protocol for propagating routing information 
i=i among multicast-enabled routers. 

The multicast backbone on the Internet (Mbone) is an extension of the Internet 
backbone to support IP multicasting. The Mbone is formed collectively by the portion of 
jji the network routers in the Internet backbone that are programmed to perform the IP 
!:;;! multicast routing protocol. Those routers in the Internet backbone that are programmed 
ilipo to handle IP multicast sessions, as well as unicast sessions, are referred to herein as 
multicast-enabled routers. The Mbone is a vktual network that is layered on top of 
sections of the physical Internet. It is composed of islands of multicast-enabled routers 
connected to each other by virtual point-to-point links called "tunnels." The tunnels 
allow multicast traffic to pass through the non-multicast-enabled routers of the Internet. 
25 IP multicast packets are encapsulated as IP-over-IP, so that they look like normal unicast 
packets to the intervening routers. The encapsulation is added upon entry to a timnel and 
removed upon exit from a timnel. This set of multicast-enabled routers, their directly 
connected subnetworks, and the interconnecting tiumels define the Mbone. For 
additional details, see (1) Comer, Douglas E. Internetworking with TCP/IP: Volume 1- 
30 Principles, Protocols, and Architectiire, Third Edition. Englewood CUffs, NJ: Prentice 
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Hall, 1995; (2) Finlayson, Ross, "The UDP Multicast Tunneling Protocol", IETF 
Network Working Group Internet-Draft, published September 9, 1998, 
http://search.ietf.org/intemet-drafts/draft-finlayson-umtp-03.txt; and (3) Eriksson, Hans, 
"MBone: The Multicast Backbone," Communications of the ACM, August 1994, Vol.37, 
5 pp.54-60. 

Since the multicast-enabled routers of the Mbone and the non-multicast-enabled 
routers of the Internet backbone have different topologies, multicast-enabled routers 
execute a separate routing protocol to decide how to forward multicast packets. The 
1 0 majority of the Mbone routers use the Distance Vector Multicast Routing Protocol 
(DVMRP), although some portions of the Mbone execute either Multicast OSPF 
(MOSPF) or the Protocol-Independent Multicast (PIM) routing protocols. For more 
details about PIM, see: Deermg, S., Estrin, D., Farrinaci, D., Jacobson, V., Liu, C, Wei, 
Q L., "Protocol Independent Multicasting (PIM): Protocol Specification", IETF Network 
:i;i5 Working Group Internet Draft, January, 1995. 

Multicasting on the Internet has a unique loss environment. On a particular path 
jjj the losses occur in bursts, as multicast-enabled routers become congested, rather than the 
losses having the characteristics associated with white noise. When packets are lost on a 
=1:20 particular link in the multicast tree, any downstream receivers lose the same packet. 

However, congestion in different parts of network is not correlated since traffic to 
receivers in other parts of the multicast tree does not necessarily pass through the same 
congested nodes and therefore does not lose the same bursts of packets. Therefore, path 
25 diversity would be a good means for recovering at least some of the missing packets, if 
there were a way to coordinate such a recovery. 

Another problem in IP multicasting is that some Internet Service Providers (ISPs) 
discriminate against multicast packets and discard them before discarding the packets for 
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other services. Therefore, it would be worthwhile balancing the efficiency of multicast 
transmissions with the quality of point-to-point transmissions. 

These problems have been solved by the Network-Based Service for the Repair of 
IP Multicast Sessions described in the above referenced, copending US patent application 
by Maxemchuk, et al. In the Maxemchuk, et al. system, a repair server polls multiple 
transmit servers to accumulate as many of the packets missing firom the multicast session 
as possible. This improves the quality of audio and video multicasts of live conferences, 
news broadcasts and similar material from one source to many receivers over the Internet. 

The invention disclosed herein is an improvement to the Maxemchuk, et al. 
system, to provide an automatic invocation of self-monitoring and ranking among several 
retransmit servers in response to the multicast source's request to have its multicast 
session repaired, which is transparent to the end user recipients of the multicast session. 
The invention disclosed herein also provides for the source's request to be authorized by a 
subscription server that causes the source to be billed for the repair service. 

Summary of the Invention 

The invention is a system and method for the automatic and transparent repair of 
IP multicast sessions. In one aspect of the invention the method repairs a multicast 
session in a network, beginning with the step of sending a request message from a source 
to a subscription server in the network, requesting a repair service for an original 
multicast session originated by the source. The method contmues by sending an enabling 
signal from the subscription server to a pluraUty of retransmit servers in the network, to 
buffer data traffic from the original multicast session, in response to the request. The 
method continues by buffering a copy of the data traffic at each of the pluraUty of 
retransmit servers and monitoring errors in each copy. The method continues by 
automatically selecting with the plurality of retransmit servers at least one refransmit 
server from among the pluraUty, having a minimum of the errors in its respective copy. 
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The method concludes by sending the respective copy as a multicast repair service to a 
repair server in the network to enable the repair server to provide a repaired multicast 
session derived from the respective copy. 

In another aspect of the invention, the method repairs a multicast session in a 
network, beginning with the step of sending a request message from a source to a 
subscription server in the network, requesting a repair service for an original multicast 
session originated by the source. The method continues by sending an enabling signal 
from the subscription server to at least one retransmit server and a repair server in the 
network, to buffer data traffic from the original multicast session, in response to the 
request. The method continues by buffering a copy of the data traffic at the retransmit 
server. The method continues by buffering the data traffic in the repair server and 
monitoring received errors therein. The method continues with the repair server 
automatically sending a request for the copy in response to the monitoring. The method 
concludes by sending the copy to the repair server to enable the repair server to 
automatically provide a repaired multicast session derived from the copy. The 
subscription server can then cause a billing system to send a bill to the source for the 
multicast repair service. 

The resultant IP multicast sessions are automatically repaired in a manner that is 
transparent to the end user recipients. 

Description of the Figures 

Figure 1 shows a multicast source sending a request to have a repair service 
provided for its multicast session. 

Figure 1 A shows a subscription server replying to the multicast source with a 
session setup message that is also sent to a plurahty of retransmit servers in the network. 
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Figure IB shows the muhicast source multicasting its original packet stream in 
the session. The figure also shows that the retransmit servers may receive only portions 
of the original packet stream during the session. 

Figure IC shows the retransmit servers transmitting a packet loss report to each 
other for the session. 

Figure ID shows the retransmit servers transmitting a repair session 
announcement to the network, about their ability to repair the source's multicast session. 

Figure IE is an overall network diagram showing the relationship of multicast 
sources, a pluraUty of retransmit servers, repair servers, and receivers in the Internet 
network. 

Figure IF is an alternate embodiment of the network of Figure IE, showing an 
alternate, bypass network used for the responses from the retransmit servers to the repair 
server, of the portions of missing packets. 

Figure 2 is a flow diagram of the retransmit server logic program. 

Figure 2A illustrates the packets currently being output by the multicast source. 

Figure 2B illustrates the packets currently being delivered to the repair server. 

Figure 2C illustrates the packets currently being delivered to the recipients by the 
repair server. 

Figure 2D illustrates the RTCP source description packet periodically output by 
the multicast source. 
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Figure 2E illustrates the RTCP sender report packet periodically output by the 
multicast source. 

Figure 2F illustrates the packets in the repaired multicast session 111' constiiicted 
by the repair server, which appear to the recipient receivers to be the same Group_l 
session transmitted from source, having the same multicast IP address and port number as 
that for the original packet stream of Figure 2 A. 

Figure 3 is a more detailed fimctional block diagram of a retransmit server 1 lOA. 

Figure 3 A shows the packets from the session received by the first rett-ansmit 

server. 

Figure 3B shows the packets from the session received by the second retransmit 

server. 

Figure 3C shows the packets from the session received by the third reti-ansmit 

server. 

Figure 3D shows the packets from the session received by the fourth reti-ansmit 

server. 

Figure BE shows the RTCP report packet tiiat is periodically output by the first 
retransmit server, reporting on the condition of the multicast Group_l session packets 
received at the retransmit server. 

Figure 3F shows the RTCP report packet that is periodically output by the second 
retransmit server, reporting on the condition of the multicast Group l session packets 
received at the retransmit server. 
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Figure 3G shows the RTCP report packet that is periodically output by the third 
retransmit server, reporting on the condition of the multicast Group l session packets 
received at the retransmit server. 

Figure 3H shows the RTCP report packet that is periodically output by the fourth 
retransmit server, reporting on the condition of the multicast Group_l session packets 
received at the retransmit server. 

Discussion of the Preferred Embodiment 

The source 102 in Figure 1, can arrange for the automatic repair of a planned 
multicast session by sending a request 1501 to the subscription server 170, in anticipation 
that losses may occur during that session due to network congestion. The source 102 will 
make arrangements with the subscription server 1501 to pay for the repair service for the 
multicast session. The subscription server 1501 then enables a repair service such as is 
described in the above referenced Maxemchuk, et al. patent application. The repair 
service will be carried out by a system of repair servers and retransmit servers which 
accumulate as many of the packets missing from the multicast session as possible. Figure 
lA shows the subscription server 170 replying to the multicast source 102 with a session 
setup message 1503 that is also sent to a plurality of retransmit servers 1 lOA. 11 OB, 
1 1 OC, and 1 1 OD in the network. In accordance with the invention, the repair service 
automatically invokes a process of self-monitoring and ranking among several retransmit 
servers, which enables the repair service to be transparent to the end user recipients of the 
multicast session. The subscription server v^dll later cause the source to be billed for the 
repair service through an appropriate billing system. 

Figure IB shows the multicast source 102 multicasting its original packet stream 
103 in the session. Figure 2 A illustrates the packets currently being output by the 
multicast source. Figure IB also shows that the retransmit servers 1 lOA, 11 OB, 1 IOC, 
and 1 lOD may receive only portions of the original packet stream 103 during the session. 
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Figures 3 A, 2B, 3C, and 3D show the packets from the session received by the retransmit 
servers 1 lOA, HOB, 1 IOC, and 1 lOD, respectively. 

Figure IE is an overall network diagram showing a multicast source 102 that is 
5 transmitting a Group_l multicast session 100, whose packets 103 are shown in Figure 
2 A. Figure 2 A illustrates the packets 103 currently being output by the multicast source 
102, with packets 28 1 to 290 being shown. The packets pass through the multicast 
enabled IP router 104 and are output on line 128 to the Internet backbone 106 (IP 
network). A second multicast source 102' is shown transmitting a second Group_2 
1 0 multicast session onto the Internet backbone 1 06. 

The plurality of retransmit servers UOA, HOB, HOC, and HOD shown in Figure 
IE, are connected to the Internet backbone 106. Each retransmit server, for example 

I lOA in Figure 1, includes a circular buffer 130A that stores a running segment of the 
15 muhicast Group_l session received from the source 102, for example the most recent 

three second interval of the received session. The session packet stream 103 sent from 
the source 102 may undergo some packet losses by the time it reaches the retransmit 
server 11 OA. Figure 3 A shows the packets 330A from the Group_l session received by 
the first retransmit server 1 lOA, namely packets 282 - 284 and 289 - 290. Note that four 

20 packets 285 - 288 are missing. Each retransmit server, for example 1 lOA in Figure 1, 
includes a buffered packet detector 134A that can identify the packets that have been 
received from the Group l session. It can also take advantage of the Real-Time Confrol 
Protocol (RTCP), discussed below, to estimate the number of packets that have been 
missed from the session. Each refransmit server, for example 11 OA in Figure 1, includes 

25 a message processor 1 32A that handles message formation and transmission and which 
handles message receipt and interpretation for message exchanges with other nodes on 
the network. Figure 3 is a more detailed ftmctional block diagram of a refransmit server 

II OA. 
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Figure 3B shows the packets 330B from the Group_l session received by the 
second retransmit server HOB, namely packets 284 - 286 and 289 - 290. Note that a total 
of five packets are missing, including packets 283, 287 and 288 which are missing. 
Figure 3C shows the packets 330C from the Group_l session received by the third 
retransmit server 1 IOC, namely packets 285 - 287 and 289 - 291. Note that a total of six 
packets are missing, including packets 283, 284, and 288 which are missing. Figure 3D 
shows the packets 33 OD from the Group_l session received by the fourth retransmit 
server HOD, namely packets 286 - 290. Note that a total of seven packets are missing, 
including packets 283 - 285 which are missing. 

The multicast source 102 uses the Real-Time Transport Protocol (RTP) to 
multicast the packets 103. The Real-Time Transport Protocol (RTP) is carried over User 
Datagram Protocol (UDP) packets over IP networks from the source 102 to the repair 
server 120A, and from the source 102 to the refransmit servers 1 lOA, 1 lOB, 1 IOC, and 
1 1 OD. RTP provides timestamps and sequence numbers. Both the retransmit servers 
11 OA, HOB, HOC, and HOD and the repair servers 120A and 120B can use this 
information to identify when some of the packets 103 are lost or arrive out of sequence. 
RTP also supports payload type identification, synchronization, encryption and 
multiplexing and demultiplexing on a per-user basis. For more detailed information on 
RTP, see (1) Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., ."RTP: A 
Transport Protocol for Real-Time Apphcations", Network Working Group Request for 
Comments Internet RFC 1889, January 1996; (2) Kosiur, D. "IP Multicasting: The 
Complete Guide to Corporate Networks", Wiley, 1998. 

Figure 2D illustrates the RTCP source description packet 103' periodically output 
by the multicast source 102. Figure 2E illustrates the RTCP sender report packet 103" 
periodically output by the multicast source 102. The Real-Time Confrol Protocol 
(RTCP) is the control protocol that is used in conjunction with RTP. Senders 102 can 
report the number of packets and bytes that are sent. Receivers can report on the loss, 
delay, and observed jitter (per sender). Other functions include media synchronization. 
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network time protocol (NTP) and RTP timestamp correlation, and session control. For 
more details on RTCP, see (1) Kosiur, D., "IP Multicasting: The Complete Guide to 
Corporate Networks", Wiley, 1998; and (2) Thomas, S., "Ipng and the TCP/IP Protocols: 
Implementing the Next Generation Internet", Wiley, 1996. 

The RTCP source description packet 103' of Figure 2D periodically describes in 
the TOOL field the media tool or application in the source 102 that is generating the 
packets 103, such as an MPEG2 video and audio compression program. The RTCP 
source description packet 103' can also describe in the NOTE field the current state of the 
source, such as the current nimiber of audio channels included in the MPEG2 
transmission. 

The RTCP sender report packet 103" in Figure 2E periodically reports the 
sender's packet count for the source 102. This is the total number of RTP data packets 
transmitted by the source 102 since starting transmission up until the time this packet 
1 03 " was generated. The RTCP sender report packet 1 03 " in Figure 2E also 
periodically reports the sender's octet count for the source 102. This is the total number 
of payload octets (i.e., not including header or padding) transmitted in RTP data packets 
by the source 102 since starting transmission up until the time this packet 103" was 
generated. This field can be used to estimate the average payload data rate. 

The retransmit servers periodically transmit RTCP receiver reports on tiie quality 
of the multicast Group_l session as received from the source 102. Figure IC shows the 
retransmit servers transmitting a packet loss report to each other for the session. Figure 
3E shows the RTCP receiver report packet 360A that is periodically output by the 
retransmit server 11 OA, reporting on the condition of the multicast Group_l session 
packets 330A received at the retransmit server. Figure 3F shows the RTCP receiver 
report packet 360B that is periodically output by the retransmit server 1 lOB, reporting on 
the condition of the multicast Group_l session packets 330B received at the retransmit 
server. Figure 3G shows the RTCP receiver report packet 360C that is periodically 
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output by the retransmit server 1 IOC, reporting on the condition of the multicast Groupl 
session packets 330C received at the retransmit server. Figure 3H shows the RTCP 
receiver report packet 360D that is periodically output by the retransmit server 1 lOD, 
reporting on the condition of the multicast Group_l session packets 33 OD received at the 
5 retransmit server. 

The format of the receiver report (RR) packet is substantially the same as that of 
the sender report (SR) packet except for minor differences, and except that the packet 
type field indicates that it is a receiver report. The remaining fields have the same 
10 meaning as for the SR packet. The RTCP receiver report includes the SSRC_n (source 
identifier) field that identifies the source 102 to which the information in this reception 
report pertains. The RTCP receiver report includes the firaction lost field which provides 
y;i the fi-action of RTP data packets fi-om source SSRC_n lost since the previous SR or RR 
B packet was sent. This fi-action is defined to be the number of packets lost divided by the 
ji; 15 number of packets expected, as defined below. The RTCP receiver report inchxdes the 
ffl cumulative number of packets lost field, which provides the total number of RTP data 

packets fi-om source SSRC_n that have been lost since the begiimmg of reception. This 
y j number is defined to be the number of packets expected less the number of packets 

actually received, where the number of packets received includes any which are late or 
=020 dupUcates. Thus packets that arrive late are not coimted as lost, and the loss may be 
negative if there are duplicates. The number of packets expected is defined to be the 
extended last sequence number received, as defined next, less the initial sequence number 
received. The RTCP receiver report includes the extended highest sequence number 
received field, which provides the highest sequence number received in an RTP data 
25 packet fi-om source SSRC_n. The RTCP receiver report includes the interarrival jitter 
field which provides an estimate of the statistical variance of the RTP data packet 
interarrival time, measured in timestamp units and expressed as an unsigned integer. The 
interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the 
difference D in packet spacing at the receiver compared to the sender for a pair of 
30 packets. This is equivalent to the difference in the "relative transit time" for the two 
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packets; the relative transit time is the difference between a packet's RTP timestamp and 
the receiver's clock at the time of arrival, measured in the same units. The interarrival 
jitter is calculated continuously as each data packet "i" is received from source SSRC_n, 
using this difference D for that packet and the previous packet i-1 in order of arrival (not 
necessarily in sequence). Whenever a reception report is issued, the current value of J is 
sampled. The RTCP receiver report includes the last SR timestamp (LSR) field that 
provides the NTP timestamp received as part of the most recent RTCP sender report (SR) 
packet from source SSRC_n. The RTCP receiver report includes the delay since last SR 
(DLSR) field, which provides the delay, between receiving the last SR packet from 
source SSRC^n and sending this reception report. Let SSRC__r denote the receiver 
issuing this receiver report. Source SSRC_n can compute the round-trip propagation 
delay to SSRC_r by recording the time A when this reception report is received. It 
calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and 
then subtracting this field to leave the round-trip propagation delay as (A- LSR - DLSR). 
This information can be transferred from the source 102 to the retransmit server 1 1 OA in 
the RTCP sender report or the RTCP source description. This field in the RTCP receiver 
report from the retransmit server 11 OA may be used as an approximate measure of 
distance between the source 102 and the retransmit server 11 OA, although some links 
have very asymmetric delays. For more details on RTCP, see Schulzrinne, H., Casner, 
S,, Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Apphcations," 
Network Working Group Request for Comments Internet RFC 1889, July 18, 1994. 

In Figure IE, the Intemet backbone is shown including a first path that includes 
multicast-enabled routers 105, respectively labeled 1 A, IB, IC, and ID, forming the 
Mbone portion that can handle IP multicast sessions, such as Group_l session 100. The 
Intemet backbone is also shown including a second path that includes non-multicast- 
enabled routers 107, respectively labeled IE and IF, which cannot can handle IP 
multicast sessions. Because heavy multicast traffic levels occur that can only be handled 
by the multicast-enabled routers 105, these routers tend to see high levels of congestion 
more often that do the non-multicast-enabled routers 107. 
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Repair servers 120 A and 120B are shown in Figure IE connected to the Internet 
backbone 106. Figure 2B illustrates the packets 109 currently being delivered to the 
repair server 120A, namely packets 281, 282, 289, and 290. Note that packets 283 - 288 
are missing from the received session. A plurality of receivers 124A, 124A', and 124A" 
are shovm connected through the multicast-enabled router 122A to the repair server 
120A. Receivers 124Aand 124A" are receiving the Group_l session. Figure 2C 
illustrates the packets 1 1 1 currently being delivered to the recipients at receivers 124A 
and 124A" by the repair server 120A, namely packets 205 - 214 which are being 
buffered for a three second delay in the repair server 120 A, before being multicast to 
receivers 124A and 124A". Receiver 124A' is receiving the second multicast Group_2 
session from repair server 120A. 

Figure IE also shows a second plurahty of receivers 124B, 124B', and 124B" are 
shown connected through the multicast-enabled router 122B to the repair server 120B. 
Receivers 124B and 124B' are receiving the Group_l session and receiver 124B" is 
receiving the Group_2 session. Figure IE also shows a subscription server 170 connected 
between the Internet backbone 106 and the billing system 172. 

Each repair server, for example 120A in Figure ID, includes a delay buffer 140A 
that stores a running segment of the multicast Group l session received from the source 
102, for example the most recent three second interval of the received session. This three 
second delay is apphed to the arriving packets 109 before they are forwarded in multicast 
mode to the receivers 124A and 124A". The session packet stream 103 sent from the 
source 102 may undergo some packet losses by the time it reaches the repair server 120A. 
Figure 2B shows the packets 109 from the Group_l session received by the repair server 
120A, namely packets 281, 282, 289, and 290. Note that packets 283 - 288 are missing. 
Each repair server, for example 120A in Figure ID, includes a missing packet detector 
144 A that can identify the packets that have been lost from the Group_l session. The 
retransmit server list 146A is compiled by a server list updating program. The list 146A 
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is an ordered list of the retransmit servers 1 lOA - 1 lOD. This list 146A is processed to 
enable the repair server 120A to identify which of the several retransmit servers 1 lOA - 
1 lOD is the most likely one to have the best copy of the Group_l session packets, in the 
event that they are needed for repair. The above-referenced Maxemchuk et al. patent 
application provides a more detailed description of the repair server I20A. 

In accordance with the invention, each of the retransmit servers, for example 

I lOA in Figure 1 A, includes a ranking logic 133A which is programmed with a ranking 
program that receives and processes the Real-Time Control Protocol (RTCP), discussed 
below, to estimate the number of packets that each retransmit server 1 lOA - 1 lOD has 
missed from the multicast Group_l session 103. The ranking program can apply a 
number of performance criteria to rank the respective retransmit servers llOA - HOD. 

The ranking criteria that the ranking program in the ranking logic 133A of the 
retransmit server 1 1 OA can apply to rank the respective retransmit servers 1 lOA - 1 lOD 
can be based on the RTCP receiver reports multicast by each of the retransmit servers 

I I OA - 1 1 OD. For example, Figure 3E shows the RTCP receiver report packet 360A that 
is periodically output by the retransmit server 1 lOA, reporting on the condition of the 
multicast Group_l session packets 330A received at the retransmit server. The RTCP 
receiver report includes the fraction lost field which provides the fraction of RTP data 
packets from source SSRC_n lost by a retransmit server 1 lOA, for example, since the 
previous SR or RR packet was sent. The RTCP receiver report includes the cumulative 
number of packets lost field, which provides the total number of RTP data packets from 
source SSRC_n that have been lost by a retransmit server 1 lOA, for example, since the 
beginning of reception. The RTCP receiver report includes the interarrival jitter field 
which provides an estimate of the statistical variance of the RTP data packet interarrival 
time experienced by a retransmit server 1 lOA, for example, measured in timestamp units 
and expressed as an unsigned integer. The round propagation delay between the source 
and a retransmit server 1 lOA, for example, which may be used as an approximate 
measure of distance between the source 102 and the retransmit server 1 lOA, 
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Assume for this example that the ranking logic 133 A in the retransmit server 
1 lOA places the retransmit servers in the order from highest to lowest as 1 lOA, HOB, 
1 IOC, 1 lOD, based on the total packets lost, as reported by the RTCP receive report 

5 which is multicast by each respective retransmit server 1 lOA - 1 lOD . Since retransmit 
server 1 lOA has reported that it has the fewest total packets lost (4 packets), it is ranked 
as the most probable to have buffered copies of the missing packets. Since retransmit 
server HOB has reported that it has the second fewest total packets lost (5 packets), it is 
ranked as the second most probable to have buffered copies of the missing packets. Since 

10 retransmit server 1 IOC has reported that it has the third fewest total packets lost (6 
packets), it is ranked as the third most probable to have buffered copies of the missing 
packets. Since retransmit server HOD has reported that it has the fourth fewest total 
packets lost (7 packets), it is ranked as the fourth most probable to have buffered copies 
of the missing packets. 

15 

Further in accordance with the invention, each respective retransmit server 1 lOA, 
HOB, HOC, and HOD compiles a ranking list in the ranking logic 133 which lists the 
retransmit servers in the order from highest to lowest as 1 lOA, HOB, 1 IOC, HOD, based 
on the RTCP receive reports which are multicast by each respective retransmit server 

20 1 1 OA - 11 OD to all others. The ranking list will be the same in each retransmit server. 
Each respective retransmit server compares its own rank in the list to the ranks of the 
others and determines if its rank lies below a pre-estabUshed threshold value. If a 
respective retransmit server llOA, HOB, HOC, or HOD determines that its rank lies 
below a pre-established threshold value, then it withdraws from further participation in 

25 providing a repair service for the multicast Group_l session 103 from the source 102. In 
this example. Since retransmit servers HOB, 1 IOC, HOD are ranked beneath retransmit 
server 1 lOA in the list in their respective ranking logic 133, retransmit servers HOB, 
HOC, 1 lOD withdraw from further participation in providing a repair service for the 
multicast session from the source 102. This leaves retransmit server 11 OA as the 
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remaining active retransmit server to continue further participation in providing a repair 
service for the multicast Group_l session 103 from the source 102. 

In response, retransmit server 1 lOA, as the remaining active retransmit server to 
5 continue further participation in providing a repair service for the multicast Group_l 
session 103, will periodically transmit Session Description Protocol (SDP) 
announcements to inform potential recipients 124 A about the existence of a multicast 
session providing a repaired version of the multicast Group_l session 103. Figure ID 
shows the retransmit servers transmitting a repair session aimouncement to the network, 
10 about their ability to repair the source's multicast session. In order to join an IP multicast 
session, software at the receiver 124 A, for example, must know the IP address and port of 
that session. One way this can be done is for the retransmit server 1 1 OA to periodically 
^ji announce this information on a well-known IP multicast session. The Session 
Q Description Protocol (SDP) used serves two primary purposes: (a) to communicate the 
= 15 existence of a session and (b) to convey sufficient information so end users may join the 
n;: session. Some of the information inchided in an SDP datagram is: the name and purpose 

of the session, time(s) the session is active, the media comprising the session, the 
J^:j transport protocol, the format, and the multicast address and port. Software developers 
y may add other attributes to SDP announcements for specific appUcations For more 
:j;i20 detailed information on SDP, see Handley, M. and Jacobson, V., "SDP: Session 

Description Protocol", Network Working Group Request for Comments Internet RFC 
2327, Nov. 1997. 

In accordance with the invention, repaired packets are transmitted from the 
25 retransmit server 1 1 OA in either a unicast session or a multicast session providing a 
repaired version of the multicast Group_l session 103. Then, the repair server 120A 
forwards the repaired session as a multicast session 1 1 T to the receivers 124A and 
124A' ' . The repaired multicast session 1 1 T is constructed by the repair server 120A by 
combining the packets 109 of Figure 2B received in the delay buffer 140A with the 
30 missing packets received from the retransmit server 1 lOA. 

17 



Bhagavath 12-30-24-5 



The repaired multicast session 1 U ' is constructed by the repair server 120A from 
the repair service multicast session received from retransmit server 1 lOA, providing a 
repaired version of the multicast Group_l session 103. Figure 2F illustrates the packets 
111' that are sequentially ordered in the delay buffer in time to be transmitted in a 
multicast session to the recipient receivers 124A and 124A'\ For example, missing 
packets 283 and 284 from the first retransmit server 1 1 OA are placed in order following 
packet 282 in the delay buffer 140A, The delay buffer 140A can be organized for indirect 
addressing of packets that are buffered at various locations in the buffer 140A. The 
pointers are sequentially addressed to provide the desired order for the output stream of 
packets 111'. Each pointer respectively points to a location in the delay buffer 140A 
where a packet having a sequence number is stored. A first pointer in the output 
sequence points to packet 282. The next pointer in the output sequence is made to point 
to the recovered packet 283. The next pointer thereafter in the output sequence is made to 
point to the recovered packet 284. In this manner, when missing packets are recovered 
from the retransmit servers, they can be stored at any available location in the delay 
buffer 140A and the pointer for that packet sequence number is made to point to the 
storage location of the recovered packet. 

The packets in the multicast session 111' of Figure 2F constructed by the repair 
server 120A resume using the RTF format. The multicast session 1 1 1' can appear to the 
recipient receivers 124A and 124A" to be the same Group_l session transmitted from 
source 1 02, as is shown in Figure 2F, having the same multicast IP address and port 
number as that for the original packet stream 103 of Figure 2 A. 

Since corrections provided by the invention are implemented by network based 
repair servers 120A and 120B and retransmit servers 1 lOA - 1 lOD, the quaHty of a 
multicast transmission is improved without changing or adding to the software in either 
the multicast source 102 or the recipient receivers 124A, 124A', 124A", 124B, 124B', or 
1 24B ' ' . This is a major improvement between the invention and prior proposed 
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techniques. If the source 102 is communicating using Real-Time Transport Protocol 
(RTP), real video, real audio, or some other multicasting protocol before the repair is 
performed, the source continues to use the same protocols after the repair. Aside from the 
improved quality of the received signal at the recipient receiver 124 A, the source 102 and 
5 recipient receivers 124 A, etc. do not see any change. 

Figure IF is an altemate embodiment of the network of Figure IE, showing an 
alternate, bypass network 600 used for the responses from the retransmit servers 1 lOA, 
etc. to the repair server 120A, of the portions of missing packets. In accordance with the 
10 invention, in response to the requests, a message processor 130A in at least one of the 
retransmit servers 1 lOA, retransmits in a bypass session to the repair server 120 A, at least 
a portion the missing packets. The retransmitted packets in the bypass session are 
y:i forwarded to circumvent at least some of the congested, muhicast enabled routers 105 in 
n the Internet backbone 106. This can be accomplished by transmitting the missing packets 
Jl^ 15 over a separate dial-up network 600 or a private virtual network 600 from the retransmit 
ra servers 1 1 OA, etc. to the repair server 120A. Another way this can be accomplished is by 

transmitting the missing packets in a unicast session from the retransmit servers 1 lOA, 
ji:; etc. to the repair server 120A. The unicast response enables non-multicast enabled 
J-j routers 1 07 in the Internet backbone to handle the response, thereby circumventing at 
;H20 least some of the congested multicast-enabled routers 105. 

Figure 3 is a functional block diagram of a retransmit server. Memory 302 is 
connected by bus 304 to the CPU processor 306 that executes the instructions in 
programs stored in memory 302. Bus 304 also connects to hard drive storage 308, 

25 network interface card 3 1 0 which connects to the Internet backbone 1 06, and network 
interface card 312 which connects to the altemate, bypass network 600 of Figure IF. 
Memory 302 has stored in it the circular buffer 130A, buffered packet detector program 
134A, message processor program 132A, subscription server message processor 352, 
multicast session quality monitoring program 354, other retransmit server monitoring 

30 program 356, internet group management protocol 332, user datagram protocol 334, 
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internet control message protocol 336, transmission control protocol 338, retransmit 
server logic program 340 which implements the ranking logic 133 A, operating system 
342, IP protocol stack 345, multicast routing daemon 355, real-time control protocol 346, 
session description protocol 348, and real-time transport protocol 350, 

5 

The primary function of the retransmit servers 1 lOA - 1 lOD is to supply any 
missing packets in an IP multicast session such as Group_l, to the repair servers 120A 
and 120B. The retransmit servers 1 1 OA - HOD must buffer packets in a session received 
from the source 102. Each retransmit server 11 OA - HOD must periodically transmit its 
10 IP address and port and the IP address and port of each multicast session for v^hich it has 
buffered packets, to enable receivers 124 A, etc, to know the availability of repair services 
for a particular multicast session. A multicast group with address, port number 
combination A, P can be reserved for the retransmit servers to communicate with the 
repair servers. 



m The mapping from IP multicast to Ethernet multicast is straightforward. The low 

order 23bits of the IP multicast address is placed in the low-order 23bits of the Ethemet 
multicast address 01 .00.5E.OO.OO.OO (hex). The mapping from IP to Ethemet multicast 

G allows for delivery of IP multicast datagrams over Ethemet LAN segments to various 

i|i20 hosts and routers participating in the multicast sessions. 

Figure 2 is a flow diagram of the retransmit server logic program. 
The flow diagram 1000 of Fig. 2 has the following steps: 

25 

Step 1 00 1 : Begin originator-initiated automatic repair of IP multicast sessions. 

Step 1 002: IP multicast source 102 registers with subscription server 170 to indicate that 

it wants a session repaired. 

Step 1004: Subscription server 170 sends this request to the retransmit servers 1 lOA, 

30 HOB, HOC, HOD. 



20 



Bhagavath 12-30-24-5 

Step 1006: Each retransmit server listens to that multicast session and evaluates its 
quality. It periodically reports the quality to other retransmit servers in the session via 
RTCP messages. 

Step 1008: A retransmit server receives periodic RTCP messages. These allow it to 
5 compare its packet loss for a specific IP multicast session to that experienced by other 
retransmit servers. 

Step 1010: If a retransmit server has more than "L%" packet loss or is not one of the 'TS[" 
retransmit servers with highest quality, then it stops listening to that session. 
Step 1012: Each retransmit server periodically transmits: (A) its DP address and port 
10 number and (B) the IP address and port number of each multicast session for which it has 
buffered packets. 

Step 1014: The repair servers 120A, 120B monitor these transmissions by retransmit 
servers to determine which retransmit servers can help repair a specific IP multicast data 
stream. 

1 5 Step 1016: If a repair server determines that packets are missing in an IP multicast data 
stream, it communicates with one or more retransmit servers that can supply the missing 
packets. 

Step 1018: The subscription server sends charges to the billing system. 



Various illustrative examples of the invention have been described in detail. In 
addition, however, many modifications and changes can be made to these examples 
without departing from the nature and spirit of the invention. 
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What is claimed is: 

1 . In a method for repairing a multicast session in a network, the steps 
comprising: 

sending a request message from a source to a subscription server in the network, 
requesting a repair service for an original multicast session originated by said source; 

sending an enabling signal from said subscription server to a plurality of 
retransmit servers in the network, to buffer data traffic from said original multicast 
session, in response to said request; 

buffering a copy of said data traffic at each of said plurality of retransmit servers 
and monitoring errors in each copy; 

automatically selecting with said plurality of retransmit servers at least one 
retransmit server from among said plurality, having a minimum of said errors in its 
respective copy; and 

sending said respective copy to repair servers in the network to enable said repair 
server to automatically provide a transparent repaired multicast session derived from said 
respective copy. 

2. The method of claim 1, wherein said plurality of retransmit servers 
periodically transmit messages to inform the repair servers about repaired multicast 
sessions that are available. 

3. In a method for repairing a multicast session in a network, the steps 
comprising: 

sending a request message from a source to a subscription server in the network, 
requesting a repair service for an original multicast session originated by said source; 

sending an enabling signal from said subscription server to at least one retransmit 
server and a repair server in the network, to buffer data traffic from said original multicast 
session, in response to said request; 

buffering a copy of said data traffic at said retransmit server; 
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buffering said data traffic in said repair server and monitoring received errors 

therein; 

said repair server automatically sending a request for said copy in response to said 
monitoring, and 

sending said copy to the repair server to enable said repair server to automatically 
provide a traasparently repaired multicast session derived from said copy. 

4, A network, including a source of multicast packets in a multicast session and a 
plurality of multicast recipients in that session, comprising: 

a subscriber server in the network, maintaining subscription information about 
said source; 

said subscriber server receiving a request from said source to establish a multicast 
session to transmit multicast packets in the network and forming a setup message; 

a plurality of retransmission servers in the network receiving said setup message 
from said subscriber server and in response, buffering portions of the packets during the 
multicast session; 

a repair server in the network providing received ones of the packets to said 
recipients during the multicast session, the repair server including a missing packet 
detector; 

said repair server automatically detecting missing packets and sequentially 
requesting missing packets from respective ones of the plurality of retransmission 
servers; 

a billing system coupled to the subscriber server, receiving charging information 
from the subscriber server about said multicast session, 

5. In a method for repairing a multicast session in a network, the steps 
comprising: 

registering a request from an IP multicast source with a subscription server to 
indicate that the source wants a multicast session repaired; 

sending the request to a plurality of retransmit servers; 

- _ _ _ _ ^3 
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listening at each retransmit server to the multicast session and evaluating its 

quality; 

periodically reporting the quality received by each of the retransmit servers, to 
other retransmit servers; 
5 comparing at each retransmit server the quality received for a specific IP multicast 

session to the quality received by other retransmit servers; 

determining if a retransmit server has more than "L%" packet loss or is not one of 
"N" retransmit servers with highest quahty, and if so then stopping the retransmit serv er 
from listening to the session; 
10 periodically transmitting by a retransmit server, its IP address and port number 

and an IP address and port number of each multicast session for which it has buffered 
packets; 

monitoring at a repair server transmissions by retransmit servers to determine 
which retransmit server can help repair a specific IP multicast data stream; 
15 determining at a repair server that packets are missing in an ff multicast data 

stream, and communicating with at least one retransmit server that can supply the missing 
packets; and 

sending charges from the subscription server to a billing system for providing a 
multicast repair service in response to the source's request. 

20 

6. The method of claim 5, wherein a plurality of retransmit servers periodically 
transmit unicast messages to inform the repair servers about repaired multicast sessions 
that are available. 

25 7. The method of claim 5, wherein a plurality of retransmit servers periodically 

transmit multicast messages to inform the repair servers about repaired multicast sessions 
that are available. 



30 



Bhagavath 12-30-24-5 



Abstract 

A system and method are disclosed for the automatic and transparent repair of IP 
muhicast sessions. The invention is a system and method for the repair of IP multicast 
sessions. In one aspect of the invention the method repairs a multicast session in a 
5 network, beginning with the step of sending a request message from a source to a 
subscription server in the network, requesting a repair service for an original multicast 
session originated by the source. The method continues by sending an enabling signal 
from the subscription server to a plurality of retransmit servers in the network, to buffer 
data traffic from the original multicast session, in response to the request. The method 

10 continues by buffering a copy of the data traffic at each of the plurality of retransmit 
servers and monitoring errors in each copy. The method continues by automatically 
selecting with the plurality of retransmit servers at least one retransmit server from 
among the plurality, having a minimum of the errors in its respective copy. The method 
concludes by sending the respective copy to a repair server in the network to enable the 

15 repair server to provide a repaired multicast session derived from the respective copy. 
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BEGIN ORIGINATOR-INITIATED 
AUTOMATIC REPAIR OF IP MULTICAST SESSIONS 
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FIG. 2 
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IP MULTICAST SOURCE 102 REGI! 

TO INDICATE THAT IT V 
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5TERS WITH SUBSCRIPTION SERVER 170 
VANTS A SESSION REPAIRED 
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1010. 



1012. 



SUBSCRIPTION SERVER 170 SENDS THIS REQUEST TO 
THE RETRANSMIT SERVERS 1 lOA, 1 lOB, 1 IOC, HOD. 
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EACH RETRANSMIT SERVER LISTENS TO THAT MULTICAST SESSION AND 
EVALUATES ITS QUALITY. IT PERIODICALLY REPORTS THE QUALITY TO 
OTHER RETRANSMIT SERVERS IN THE SESSION VIA RTCP MESSAGES. 
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A RETRANSMIT SERVER RECEIVES PERIODIC RTCP MESSAGES. THESE 
ALLOW IT TO COMPARE ITS PACKET LOSS FOR A SPECIFIC IP MULTICAJ 
SESSION TO THAT EXPERIENCED BY OTHER RETRANSMIT SERVERS. 
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IF A RETRANSMIT SERVER HAS MORE THAN T%" PACKET LOSS OR 
IS NOT ONE OF THE "N" RETRANSMIT SERVERS WITH HIGHEST QUALITY. 
THEN IT STOPS LISTENING TO THAT SESSION. 




r 



EACH RETRANSMIT SERVER PERIODICALLY TRANSMITS: (A) ITS IP ADDRESS 
& PORT NUMBER AND (B) THE IP ADDRESS AND PORT NUMBER OF EACH 
MULTICAST SESSION FOR WHICH IT HAS BUFFERED PACKETS 





r 


THE REPAIR SERVERS 120A, 120B MONITOR THESE TRANSMISSIONS BY 
RETRANSMIT SERVERS TO DETERMINE WHICH RETRANSMIT SERVERS CAN 
HELP REPAIR A SPECIFIC IP MULTICAST DATA STREAM. 




r 


IF A REPAIR SERVER DETERMINES THAT PACKETS ARE MISSING IN AN 
IP MULTICAST DATA STREAM, IT COMMUNICATES WITH ONE OR MORE 
RETRANSMIT SERVERS THAT CAN SUPPLY THE MISSING PACKETS. 
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THE SUBSCRIPTION SERVER SENDS CHARGES TO THE BILLING SYSTEM. 
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IN THE UNITED STATES 
PATENT AND TRADEMARK OFFICE 

Declaration and Power of Attorney 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my 

name. 

I believe I am an original, first and joint inventor of the subject matter which is 
claimed and for which a patent is sought on the invention entitled A Network-Based 
Service For Originator-Initiated Automatic Repair Of IP Multicast Sessions, the 

specification of which is attached hereto. 

I hereby state that I have reviewed and understand the contents of the above 
identified specification, including the claims, as amended by an amendment, if any, 
specifically referred to in this oath or declaration. 

I acknowledge the duty to disclose all information known to me which is material 
to patentability as defined in Title 37, Code of Federal Regulations, 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 1 19 of 
any foreign application(s) for patent or inventors' certificate listed below and have also 
identified below any foreign application for patent or inventors' certificate having a filing 
date before that of the application on which priority is claimed: 

None 

I hereby claim the benefit under Title 35, United States Code, 120 of any United 
States application(s) listed below and, insofar as the subject matter of each of the claims 
of this apphcation is not disclosed in the prior United States appUcation in the manner 
provided by the first paragraph of Title 35, United States Code, 112, we acknowledge the 
duty to disclose all information known to us to be material to patentability as defined in 
Title 37, Code of Federal Regulations, 1.56 which became available between the filing 
date of the prior appUcation and the national or PCT international filing date of this 
application: 



None 
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I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and behef are believed to be true; and further 
that these statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 
18 of the United States Code and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 

I hereby appoint the following attomey(s) with full power of substitution and 
revocation, to prosecute said application, to make alterations and amendments therein, to 
receive the patent, and to transact all business in the Patent and Trademark Office 
connected therewith: 



Samuel H. Dworetsky 
Thomas A. Restaino 
Jose de la Rosa 
Michele L. Conover 
Robert B. Levy 
Benjamin S. Lee 
Alfired G. Steinmetz 



(Reg. No. 27873) 
(Reg. No. 33444) 
(Reg. No. 34810) 
(Reg. No.34962) 
(Reg. No. 28234) 
(Reg. No. 42787) 
(Reg. No. 22971) 



I also appoint Christopher A, Hughes (Reg. No. 26914) and John E. Hoel (Reg. 
No. 26279) of Morgan & Finnegan as associate attorneys, with full power to prosecute 
said application, to make alterations and amendments therein, and to transact all business 
in the Patent and Trademark Office coimected therewith. 



Please address all correspondence to Mr. S. H. Dworetsky, AT&T Corp., P.O. 
Box 4110, Middletown, New Jersey 07748. Telephone calls should be made to Michele 
L. Conover at 908-903-6011. 



Full name of 1^ joint inventor: Vijay K. Bhagavath 

Inventor's signature V>)-^ k-?V-'-;^v^'^^ Date ^rlll 

Residence: Lincroft, Monmouth County, New Jersey 
Citizenship: India 

Post Office Address: 45 Broadmoor Drive 

Lincrofl, New Jersey 0773 8 
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Full name of 2"'' joint inventor: Joseph Thomas O'Neil 

Inventor's signature ^O^t^fyL 9lL4^a4^ ^/C^^ Date -^AAf 

Residence: Staten Island, Richmond County, New York 

Citizenship: United States of America 

Post Office Address: 40 Hawley Avenue 

Staten Island, New York 103 12 
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Full name of 3"^ joint inventor: David Hilton Shur 

Inventor's signature ^puuiet Date KM ij, n 

Residence: Aberdeen, Monmouth County, New Jersey 

Citizenship: United States of America 

Post Office Address: 241 Perth Hill Court 

Aberdeen, New Jersey 07719 
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Full name of 4 joint inventor: Aleksandr Zelezniak 

Inventor's signature e^*^ J ^ ^ Date 

Residence: Matawan, Monmouth County, New Jersey 

Citizenship: Lithuania 

Post Office Address: 29 Crest Circle 

Matawan, New Jersey 07747 



